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ABSTRACT 



A cryptographic system and method for encrypting and 
decrypting data using public key cryptography. The encryp- 
tion and decryption may be divided into tasks that may 
operate in parallel. A secure method of initializing the 
cryptographic system to allow for secure operations and 
protect against tampering with application software. The 
application program is retrieved from an encrypted file in 
external memory and authenticated before being executed. 

6 Claims, 5 Drawing Sheets 
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CRYPTOGRAPHIC SYSTEM 
BACKGROUND OF THE INVENTION 

This invention relates generally to communicating data 
securely, and more particularly to a cryptographic system 5 
and methods of using public key cryptography. 

Computer systems are found today in virtually every walk 
of life for storing, maintaining, and transferring various 
types of data. The integrity of large portions of this data, 
especially that portion relating to financial transactions, is 10 
vital to the health and survival of many commercial enter- 
prises. Individual consumers also have an increasing stake in 
data security as open and unsecure data communications 
channels for sales transactions, such as credit card transac- 
tions over the Internet, gain popularity. 15 

Protecting data stored in computer memory, tape, and disk 
is often important. However, just as important, if not more 
so, is the ability to transfer financial transactions or other 
communications from a sender to an intended receiver _ 

20 

without intermediate parties being able to interpret the 
transferred message. Furthermore, as important transactions 
are increasingly handled electronically, authentication of the 
originator of a message must be ensured. For example, for 
electronic banking, there needs to be a way to authenticate ^ 
that an electronic document, such as a bank draft, has 
actually been "signed" by the indicated signatory. 

Cryptography, especially public key cryptography, has 
proven to be an effective and convenient technique of 
enhancing data privacy and authentication. Data to be 30 
secured, called plaintext, is transformed into encrypted data, 
or ciphertext by a predetermined encryption process of one 
type or another. The reverse process, transforming ciphertext 
into plaintext, is termed decryption. In public key 
cryptography, the processes of encryption and decryption 35 
are controlled by a pair of related cryptographic keys. A 
"public" key is used for the encryption process, and a 
"private" key is used to decrypt ciphertext. Alternatively, the 
private key may be used to encrypt the data, and the public 
key to decrypt it. This latter method provides a method of 40 
digitally signing data to positively identify the source of the 
data. 

The prior art includes a number of public key schemes. 
However, over the past decade, one system of public key 
cryptography has gained popularity. Known generally as the 45 
"RSA" scheme, it is now thought by many to be a worldwide 
defacto standard for public key cryptography. The RSA 
scheme is described in U.S. Pat. No. 4,405,829. 

The RSA scheme capitalizes on the relative ease of 
creating a composite number from the product of two prime 50 
numbers whereas the attempt to factor the composite num- 
ber into its constituent primes is difficult. Pairs of public/ 
private keys can then be found based on the factors of the 
composite number. A message is encrypted using a series of 
mathematical exponentiations and divisions based on one of 55 
the keys. If the matching key of the public/private key pair 
is known, the message can be decrypted using a series of 
mathematical exponentiations and divisions using the 
matching key. The composite number is a part of the public 
and private keys so it is known to the public. However, since 60 
the private key can only be found by factoring the composite 
number, calculating the private key from the public key is 
computationally difficult. 

The security of the RSA technique can be enhanced by 
increasing the difficulty of factoring the composite number 65 
through judicious choices of the prime numbers. (This, of 
course would be true for any encryption/decryption scheme 
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using or requiring prime numbers.) Another, and principle 
enhancement, is to increase the length (i.e., size) of the 
composite number. Today, it is common to find RSA 
schemes being proposed in which the composite number is 
on the order of 600 digits long. The task of exponentiating 
a number this long, however, can be daunting and time 
consuming, although not as difficult as factoring. Therefore, 
increasing the length of the composite number increases the 
security, but only at the expense of increased time to perform 
the encryption and decryption. 

However, recently discovered techniques have greatly 
improved the efficiency with which encryption/decryption 
functions are performed using the RSA scheme. Rather than 
using two prime numbers to form the composite number 
conventionally employed in RSA cryptographic operations, 
it has been found that more than two prime numbers can also 
be used. In addition, it has also been found that the Chinese 
Remainder Theorem can be used to break an RSA encryp- 
tion or decryption task into smaller parts that can be per- 
formed much faster than before. 

In addition to the security of the data, another important 
issue with regard to cryptographic systems is the security of 
the system itself. In a system implementing an encryption 
algorithm, ensuring that the system is secure from tampering 
is important. One area of concern is the secure loading and 
storing of application programs for the system. If the appli- 
cation program can be altered or substituted, the security of 
a system may be breeched. 

It is therefore desirable to provide an efficient crypto- 
graphic system for implementing public key cryptography 
with multiple prime factors. It is also desirable to provide a 
cryptographic system that may be initialized to a secure state 
while providing maximum flexibility for the user in provid- 
ing application programs to the system, 

SUMMARY OF THE INVENTION 

A cryptographic system is provided having a processor 
and a plurality of exponentiation units. The processor 
receives encryption or decryption requests from a host 
processor and divides them into one or more exponentiation 
tasks. These exponentiation tasks are transferred to one or 
more execution units that perform the exponentiation and 
return a value to the processor. This allows the exponentia- 
tions tasks to be performed in parallel, thereby decreasing 
the time needed to perform the encryption and decryption 
requests. 

The present invention further provides a method of ini- 
tializing the cryptographic system in a secure manner. An 
external memory holds a first program file along with header 
information, a hash value, and a digital signature in an 
encrypted program packet. The first program file contains a 
key/option table holding an RSA cryptographic public key. 
A processor loads the encrypted program packet and 
decrypts it using a cryptographic key, however the resulting 
program file is only executed by the processor after authen- 
ticating it. If it cannot be authenticated, then the crypto- 
graphic keys are zeroed out, and the cryptographic system is 
put into a non-functioning state. 

The first program file is authenticated by checking the 
header for proper format, computing an expected hash value 
of the first program file and comparing it with the hash value, 
and checking the digital signature with an RSA public key 
that is stored in the cryptographic system. 

After authenticating this first program file, the processor 
executes the first program file. The first program file loads a 
second program file from the external memory. This second 
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program file is generally a user-application program. It is 
authenticated in a similar manner to the first program file, 
but the digital signature is checked against the RSA public 
key found in the key/option tabic. 

By this initialization process, the user of the crypto- 
graphic system may load personalized application programs 
with secret cryptographic keys not known to anyone else. 
The process ensures that the application programs cannot be 
altered or substituted with fraudulent programs. At the same 
time, the manufacturer of the cryptographic system can 
securely provide maintenance and upgrade programs over 
public networks, and ensure that only properly licensed 
users are using the programs. 

A further understanding of the nature and advantages of 
the inventions presented herein may be realized by reference 
to the remaining portions of the specification and the 
attached claims. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 shows, in block diagram form, a cryptographic 
system; 

FIG. 2 illustrates the cryptographic processor forming a 
part of the cryptographic system of FIG. 1; 

FIG. 3 illustrates, in block diagram form, the crypto- 
graphic coprocessor; 

FIG. 4 is a flow diagram of a secure startup program used 
to initialize the cryptographic system of FIG. 1; 

FIG. 5 shows a possible structure of a cyphertext program 
packet; and 

FIG. 6 is a flow diagram of a secondary loader program 
that may be used to load user applications. 

DESCRIPTION OF THE SPECIFIC 
EMBODIMENT 

Turning now to the figures, and for the moment, FIG. 1, 
there is illustrated a cryptographic system 100 constructed 
according to the teachings of the present invention to 
implement RSA public key cryptography — although, as will 
be evident to those skilled in this art, other cryptographic 
schemes may be used. In operation, data is brought into 
cryptographic system 100 from an external source (not 
shown) such as a host computer, a network, or other source. 
The external source is connected to cryptographic system 
100 through a connector 103. Cryptographic system 100 
operates to receive data and instruction from the external 
source or host, to encrypt or decrypt the data, and return it 
to the host. 

Preferably, the communicating medium connecting the 
host (not shown) and the cryptographic system 100 is a 
peripheral component interconnect (PCI) bus because, 
among other things, of its processor independence. 
However, it will be evident to those skilled in this art that 
other bus structures may be used, and even preferred given 
different host environments. 

The connector 103 is coupled to a pair of processing 
boards 107 by a host interface 105. The processing boards 
107 are each substantially identical in design and 
construction, so that a description of one will apply equally 
to the other. Each processing board 107 is separately addres- 
sable and may operate in parallel with the other. 

As FIG. 1 shows, the processing boards 107 include a 
cryptographic processor 110 that operates, in response to the 
instructions from the host (not shown), to perform encryp- 
tion or decryption. To accelerate the exponentiation tasks 
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requested of the cryptographic processor U0, one or more 
cryptographic co-processors 115 and a reconfigurable 
co-processor 117 are provided. The cryptographic 
co-processors 115 are specially constructed to perform, 
quickly, the various exponentiations necessary to most cryp- 
tographic tasks. The cryptographic co-processors 115 are 
described in greater detail below in connection with FIG. 3. 

Data is transferred between cryptographic processor 110 
and cryptographic coprocessors) 115, and reconfigurable 
coprocessor 117 by a secure bus 120. Secure bus 120 carries 
address, control and data lines — as well as any chip select 
lines that may be used. To preserve the security of the 
cryptographic system 100, all information of a secure nature 
is encrypted before being placed on secure bus 120. In the 
specific embodiment, a DES engine, capable of DES encryp- 
tion and decryption, is included in cryptographic processor 
110, cryptographic coprocessors) 115, and reconfigurable 
coprocessor 117 for providing the encryption and descrip- 
tion for secure bus 120. Of course, other types of security, 
other than DES may be provided, depending upon how 
much security is required and the resources available to 
provide the security. 

Although the cryptographic processor 110, as will be 
seen, is constructed to include memory, additional memory, 
external to the cryptographic processor 110, is provided in 
the form of a flash memory 124 and a random access 
memory (RAM) 126. Data is transferable to flash memory 
124 and a random access memory (RAM) 126 by way of 
secure bus 120. In the specific embodiment, flash memory 
124 has two megabytes of storage capacity. Its primary use 
in the specific embodiment is as a repository for a user- 
application program. A user-application program is 
encrypted and stored in flash memory 124 along with 
information to protect it from unknown alteration. After the 
system is successfully booted and the user-application pro- 
gram loaded into cryptographic processor 110, tests are done 
to ensure its authenticity before control of the system is 
transferred to the user-application program. Details of an 
exemplary method of securely booting the system and 
loading an application program are presented below with 
respect to FIGS. 4 and 6. 

The RAM 126 is used for the storage of both secure and 
unsecure data. In the specific embodiment, it is one mega- 
byte of volatile memory. 

Cryptographic processor 110 is provided with the output 
of crystal oscillator 155 from which it generates clock 
signals for its own use and for use by other components of 
cryptographic system 100. A battery 162 is also optionally 
provided to supply backup power during a power failure. Its 
use is not required by the present invention. 

FIG. 2 depicts a more detailed description of crypto- 
graphic processor 110, Preferably, cryptographic processor 
110 is physically secure from inspection and tampering by 
outside sources. In the specific embodiment, it meets the 
Federal Information Protection System (FIPS) level 3 stan- 
dard. A currently available cryptographic processor 110 is 
the VMS310 — NetArmor™ Encryption Processor available 
from VLSI Technology, Inc., in San Jose, Calif. 

As FIG. 2 shows, the cryptographic processor 110 
includes a central processor unit (CPU) 210 as the main 
controller of the system. CPU 210 executes initialization 
sequences and user-application programs. It receives data 
and instructions from the external host and breaks the 
instructions down into tasks as required or necessitated by 
the user-application program. It assigns some of the tasks to 
other specialized units (e.g., the one or more cryptographic 
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co-processors 115) as will be described below. In the specific cryptographic processor 110 connects to secure bus 120 by 

embodiment, CPU 210 is a 32-bit Advanced RISC Machine a secure bus interface 246. Secure bus interface 246 provides 

(ARM) 7 processor. This is a RISC-based processor con- the driver and receiver circuits for the signal lines that make 

structed for pipeline operation. However, many different up the secure bus 120. 

processors will be appropriate for use in a similar system. 5 Before being placed on secure bus 120, data is first 

CPU 210 is coupled with other elements within crypto- encrypted to make it secure by the DES bus encryption 

graphic processor 110 by means of a data/address bus 215. engine 250, using Data Encryption Standard, an American 

Data/address bus 215 is also coupled to host interface 105 National Standards Institute (ANSI) approved standard for 

through a bus interface 217. Bus interface 217 provides a data encryption (ANSI X3.92). The DES engine 250 is 

path to host interface 105, while keeping data/address bus 10 configured to operate at 20 Mbytes per second and will 

215 secure from unwanted monitoring. Encryption and operate in either ECB or CBC modes. Details of the DES 

decryption requests are delivered to CPU 210 over data/ protocol are well known in the art of cryptography and may 

address bus 215 through bus interface 217, and the results be found, for example, in U.S. National Bureau of Standard, 

are returned by the same path. In the specific embodiment, "Data Encryption Standard," Federal Processing Standard 

data/address bus 215 is a 32-bit data bus with control and 15 (FIPS) Publication 46, January 1977. However, the present 

address signals. Data on data/address bus 215 is not neces- invention is not limited to DES protocol for secure bus 120. 

sarily encrypted, but is kept secure from tampering with Other encryption algorithms, now known or yet to be 

physical security that is built into the chip that prevents developed, may also be used to make secure bus 120 secure, 

probing of the chip. The keys for the DES encryption performed by the DES 

During its operation, CPU 210 may have its operation 20 engine 250 are generated randomly and stored by CPU 210. 

interrupted by certain events. An interrupt circuit 225 is As such, no human need ever know the DES keys. In the 

provided for sensing an interrupt event and communicating specific embodiment, these keys are stored in real time clock 

the event to CPU 210. This is a common practice and a (RTC RAM) 255 that has a small amount of RAM provided, 

design for interrupt circuit 225 will be readily apparent to RTC RAM 255 has an external battery 257. This protects the 

one of skill in the art. 25 contents of RTC RAM 255 when power is removed from the 

As FIG. 2. shows, the cryptographic processor 110 incor- system, 

porates various support devices, including random access The RSA engine 260 is a special purpose arithmetic unit 

memory and read-only (RAM 230 and ROM 240), an designed and structured to perform fast modular exponen- 

encryption/decryption engine (DES engine 250) for encrypt- ^ tiation. In the specific embodiment, it performs 10 exponen- 

ing and decrypting information communicated on the secure tiations per second on a 1024 bit value. Its design and 

bus 120, an exponentiator circuit 260, and hashing engine operation will be understood by one of skill in the art. If 

270. These components are all communicated to CPU 210 another encryption method besides RSA public key cryp- 

by data/address bus 215. tography is provided by the system, other types of arithmetic 

The random access memory (RAM) 230 is provided as 35 units may be provided along with or instead of RSA engine 

memory for use by CPU 210. In the specific embodiment, it 260. 

is a two-kilobyte RAM with a 32-bit data input. It may be In operation, the cryptographic system 100 (FIG. 1) will 

used for storing the user-application program upon which receive an encryption request or a decryption request from 

CPU 210 operates, and as a scratchpad memory for tempo- the host (not shown) via messages that connects the system 

rary storage of data and variables. It is coupled to CPU 210 4Q to the host. The encryption request will include the message 

by data bus 215. data to be encrypted and, perhaps, the encryption keys. 

ROM 240 is what is known as a volatile ROM or VROM; Alternatively, the encryption keys may be kept in RAM 126 

it is a read-only memory that is physically secure from (FIG. 1) or RAM 230 (FIG. 2) of the cryptographic proces- 

tampering or probing. A purpose of ROM 240 is as a sor 110. The decryption request will include the cyphertext 

repository for startup software which is installed in the 45 and the decryption keys. The request and any accompanying 

factory and may not be altered. The startup software in ROM keys, are passed to cryptographic processor 110 of one of the 

240 is executed automatically by CPU 210 when power is processing boards 107 by the host interface 105. 

applied to the system. This allows the system to initialize For public key RSA, the CPU 210 of the cryptographic 

itself securely. Additional details of the startup software will processor 110 receiving the request will construct exponen- 

be provided with respect to FIG. 4 below. 50 tiation tasks for execution by RSA engine 260 from the 

A device select decoder 244 operates to decode certain message data and the keys. RSA engine 260 performs 

address ranges and provides signals to select certain external exponentiations and returns the results to CPU 210. As 

devices. Though not a necessary element of the present described above, the encryption and decryption may be 

invention, device select decoder 244 reduces the amount of broken into one or more exponentiation tasks. These tasks 

logic needed on external devices to decode addresses and to 55 can be performed in parallel to speed up the operation. The 

add flexibility to external devices. In the specific individual results of the exponentiation tasks are combined 

embodiment, device select lines are used to enable indi- using the principles of the Chinese Remainder Theorem by 

vidual cryptographic coprocessors 115. CPU 210 to form the result — as described in the aforemen- 

In the specific embodiment, secure bus 120 (FIG. 1) is tioned patent application Ser. No. 08/085,993, which was 

connected to a secure memory management unit (MMU) 60 previously incorporated by reference, 

forming a part of the CPU 210. Of course, if another device To speed up performance of the exponentiation tasks, the 

is used as CPU 210 that does not have a secure MMU, work may be offloaded on secure bus 120 to cryptographic 

additional circuitry outside CPU 210 may be used to provide coprocessor 115. Topically, cryptographic coprocessor 115 

secure bus 120. However, the MMU of CPU 210 operates to is a specialized processor capable of performing multiple 

effectively shield the internal data bus 215 from external 65 exponentiations or other cryptographic calculations at a 

probing, thereby securing internal information of the cryp- greater rate. More details regarding cryptographic coproces- 

tographic processor 110 from surreptitious inquiry. The sor 115 will be given with respect to FIG. 3 below. 
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The hashing engine 270 is provided as part of the cryp- 
tographic processor 110 to calculate an expected hash value 
for a message provided to it. The expected hash value is 
generally a checksum value used to verify that the message 
has not been altered. If the expected hash value matches a 
hash value that was generated earlier and appended to the 
message, then a degree of confidence is gained in the 
validity of the message. The amount of confidence is based 
upon the hash algorithm used. In the specific embodiment, 
hash engine 270 performs a FIPS 180-1 compliant Secure 
Hash Algorithm (SHA-1.) SHA-1 produces a 160-bit hash 
value. 

Hash values are appended to messages sent over secure 
bus 120. If the message changes en route, the hash value that 
is attached to the data will not match the expected hash value 
that is computed for the message at the other end. 

Physical security circuits 280 are also incorporated in 
cryptographic processor U0 to monitor the battery level and 
the VCC level. The physical security circuits operate to 
detect voltage levels which tend to indicate that the chip is 
possibly being tampered with and provide an alarm to CPU 
210. Included in physical security circuits is a non-volatile 
VROM 282. VROM 282 is a memory that is physically 
secure, and one-time programmable. It is programmed with 
a seed for generating DES keys, the public key of an RSA 
public/private key pair, and an ICF flag. The uses of these 
components will be explained below with respect to FIG. 4 

FIG. 3 depicts a more detailed block diagram of crypto- 
graphic coprocessor 115. Data is communicated between 
cryptographic coprocessor 115 and secure bus 120 through 
I/O pins 312 which connect to an I/O controller router 310 
by a data bus 316 and a control bus 318. As described herein, 
cryptographic co-processors 115 are each on a separate 
VLSI components. However, if it resided on the same 
component as cryptographic processor 110, I/O pins 312 
would not be necessary. In the specific embodiment, data bus 
316 is a 32-bits wide data bus. One of the signals on control 
bus 318 may be a device select signal. The device select 
signal is decoded from an address range that is assigned to 
a particular cryptographic coprocessor 115. This may be any 
range addressable by the addressing bandwidth of CPU 210. 
As mentioned above, cryptographic processor 110 may 
include device select decoder 244 (FIG. 2) for providing the 
device select signal. When an address in the defined range is 
referenced, the device select signal is asserted for the 
particular cryptographic coprocessor 115. 

As FIG. 3 further shows, the I/O controller router 310 of 
the cryptographic co-processor 115 is coupled by a data/ 
control bus 320 to a DES cell 330 and a number of 
exponentiation cells 340. The DES cell 330 operates as a 
companion to the DES engine 250 of the cryptographic 
processor 110 (FIG. 2). In fact, it is designed in much the 
same way as the DES engine 250 to decrypt data received 
from the secure bus 120, and to encrypt data to be commu- 
nicated to the cryptographic processor 110. The exponen- 
tiation cells 340 are substantially identical to one another, 
and are special purpose arithmetic units designed and struc- 
tured to do fast exponentiation. In the specific embodiment, 
cryptographic co-processor 115 includes six exponentiation 
cells 340, although this number may be greater or fewer 
depending on the needs of the user and the capabilities of the 
technology. The specific embodiment of cryptographic pro- 
cessor 110 allows the attachment of up to eight crypto- 
graphic co-processors 115 to a single cryptographic proces- 
sor 110. 

In operation, a cryptographic coprocessor 115 receives 
tasks from the cryptographic processor 110 (i.e., the CPU 
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210) and returns results of such tasks. Data received by I/O 
controller router 310 is generally encrypted. If so, it is sent 
to the DES cell 330 for decryption before being routed to an 
available exponentiation cell 340. The exponentiation cell 

5 performs the exponentiation, and the results are encrypted 
by DES cell 330 and sent back to cryptographic processor 
110. Typically, the exponentiation calculations will take 
much more time than the DES encryption/decryption. 
Therefore, having only one engine encryption/decryption 
(i.e., DES cell 330) does not generally cause a bottleneck to 

1 the throughput. However, if needed, multiple DES cells 330 
may be provided. 

FIG. 4 illustrates, in flowchart form, the initialization 
procedure 400 used to start up cryptographic system 100 
upon reset, and to possibly place the cryptographic system 

15 100 in a secure state. Typically, the method is implemented 
as a series of software instructions that reside in a system 
memory, i.e., ROM 240 (FIG. 2). Whatever memory is used 
to contain the process that implements the initialization 
method shown in FIG. 4 should be a secure memory so that 

20 it cannot be altered after its manufacture. ROM 240 is an 
example of such a secure memory. At the time of 
manufacture, software instructions are hardwired into ROM 
240. The contents may not be externally probed or altered 
without destruction, nor can the ROM 240 be read by 

25 external (to the cryptographic processor 110) sources. The 
MMU of the CPU 210 operates to isolate and shield the data 
bus 215, and thereby the content of ROM 240, from sur- 
reptitious access. 

3Q The software operates on a processor such as CPU 210. 
CPU 210 is constructed or otherwise configured so that the 
software in ROM 240 is automatically executed after a 
system reset before any other software. A purpose of this 
feature is to place the system in a secure state, and perhaps 

35 to load a proper application program. This ensures that the 
user knows which program is executing, and that the system 
is properly secured before any sensitive data is allowed to be 
brought into the system. 

Referring to FIG. 4, at step 402 a chip reset occurs 

^ because of system power-up or other system reset. In this 
step, CPU 210 performs a self-test on the system and 
initializes all of the volatile registers to known values. 

After initialization is completed, in step 404, CPU 210 
examines its registers to determine if it is in a secure state or 

45 an unsecure state. Initially, the system will be in an unsecure 
state. Only a system that was previously in a secure state 
before powering down or being reset will be initiated to the 
secure state upon chip reset. 

If in step 404, CPU 210 determines that it is in a secure 

50 state, in step 406 it generates its DES keys from seed values 
found in RTC RAM 255, VROM 282, and ROM 240. These 
keys are stored in volatile RAM, so they must be regenerated 
each time the system is initialized. After generating the keys, 
CPU 210 proceeds to step 410 in which it loads a black boot 

55 program from flash memory. The details of step 410 will be 
given more completely below. 

If CPU 210 finds that it is not in a secure state, it proceeds 
to step 412 in which it waits for a command from the host 
(not shown.) Some time later, since CPU does not have a 

60 program to execute, the host issues a command to load a 
program. CPU examines the command, and it determines 
whether the command is to load a secure program or a 
normal (i.e., non-secure) program. The process for executing 
non-secure programs is illustrated below with respect to 

65 steps 650-685. 

In order to execute a secure program, the system must be 
put into the secure state. In step 416, the cryptographic keys 
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are generated from RTC RAM 255, VROM 284, and the with a private key of an RSA public/private pair. The hash 

ROM 240 as in step 406. Then, in step 420, the host loads value 540 developed from the program file before encryp- 

a program file 510 (FIG. 5) to the cryptographic system 100. tion and stored in flash memory 124 is itself encrypted by the 

In step 420, program file 510 is a Sccure_Load program RSA scheme, using the private key of the pair, before being 

designed to securely load a program from the flash memory 5 added to the trailer 530 of the program packet as the 

124. The program file is encrypted inside an encrypted signature 550. The VROM 282 is programmed with the 

program packet 500 (FIG. 5) because it comes from the host public key of the pair when the cryptographic system is 

outside the secure portion of the cryptographic processor manufactured. When the program packet is decrypted, and a 

110. The encrypted program packet 500, in addition to being hash value produced from the decrypted version of the 

encrypted, preferably includes other protection to ensure its 10 program file 510, the accompanying signature 550 is then 

authenticity. decrypted using the public key retrieved from the VROM 

In step 424, the encrypted program packet is decrypted 282, and the decrypted result compared to the created hash 

and verified for authenticity. In the specific embodiment, the value. A match furnishes an added confidence that the 

decryption is accomplished by DES engine 250. The program packet 500, and in particular the program file 510 

decrypted result, a program packet that includes the program 15 it contains, was indeed generated from a source that was 

file and additional header and trailer information, is prefer- intended. 

ably subjected to further checks before loading the Secure_ If, however, the digital signature is incorrect, i.e., the hash 

program into the CPU memory. These checks are done using value created by the hash engine 270 docs not match that 

the header and trailer information, to gain a level of confi- resulting from the RSA decryption of the signature 550, the 

dence that the program is the one that is intended to be run. 20 initialization is aborted to the key erasure step of step 427, 

Digressing for the moment, FIG. 5 depicts an example of and the cryptographic system 100 placed in the non- 

a format for the encrypted program packet. Preferably, the functioning state 462. 

encrypted form of the program packet is triple-DES encoded Recognizing that spurious errors may occur during trans- 
using CBC mode. As FIG. 5 shows, the encrypted program mission or checking of the encrypted program packet 500, 
packet 500 contains a program file 510 (for execution by 25 rather than aborting to the non-functioning state immedi- 
CPU 210) preceded by a header 520 and followed by a ately upon detection of a anomaly in the checking scheme, 
trailer 530. The header 520 contains information about the in the specific embodiment, CPU 210 makes three attempts 
program packet 500 such as the length of the program file to authenticate the program before aborting to step 427. 
and its starting address. The trailer 530 contains additional If tne checks performed at step 424 show that the 
security information such as a hash value 540 and a digital 30 encrypted program file 510 is authentic, the Secure_Load 
signature 550. file 510 ^ assumed to be correct, and is then written to the 

Returning to step 424 of FIG. 4, after the program packet RAM 230. In step 430, the keys are zeroized and the state 
500 is decrypted by the DES engine 250, it is then examined is set to the secure state. Then in step 435, control of the 
to determine that the decrypted program file has a valid CPU 210 (and thereby the cryptographic system 100) is 
program length and starting address as specified by the (also transferred to now RAM-based Secure_Load program 510. 
decrypted) information of the header 520. Finding that the Although the Secure_Load program may be changed 
format is correct provides a level of confidence that the from time to time, this method provides a level of confidence 
decryption was properly performed, and/or that the that the program file 510 has not been altered or replaced by 
decrypted program file was that retrieved from the host, i.e., 4o a fraudulent program. This allows a great amount of 
that there has not been clandestine attempt to introduce a flexibility, while still providing security. Furthermore, main- 
fraudulent program file that could operate to extract confi- tenance updates and program enhancements may be made 
dential information from the cryptographic processor 110. by s^pty changing the program that is downloaded from 

If the program packet format is not what is expected, the the host. If it is properly signed, any program may be loaded, 
system will exit step 424 in favor of an abort mode at step 45 Also, since the program is signed by the private key, but may 
427. Here, to protect itself from unwanted intrusion, the be verified by the public key, the private key does not need 
cryptographic system 100 will erase all cryptographic keys to be stored anywhere on the system, 
(i.e., the keys in RTC RAM 255) in step 427, and the Mlcr control of CPU 210 is transferred to the program 
cryptographic system 100 is then placed in a non- file, which in this step is the Secure_Load program, step 410 
functioning state. It remains in this state, until the crypto- 5Q ( a i rea dy mentioned above) loads a secondary loader pro- 
graphic system 100 is reset. Since the initialization apro- gram re f er red to as a black boot program from the Flash 
gram did not complete, nothing about the system can be Memory 124. 

assumed to be secure, so secret data should not be allowed. r** r ,u * ,t_ . 1 1 . 

' Digressing for the moment, the black boot program is a 

If the packet format is determined to be correct, however, program that may be customized for each user, by allowing 

hash value 540, a checksum developed from the original 55 the user to put personalized RSA keys and set other options 

(plaintext) form of the program file 510 is checked against m a key/option table, these keys being unknown to anyone 

that developed by the hash engine 270 after decryption. If a e lse. The manufacturer or other provider of the crypto- 

hash of the program file matches hash value 540, then a level gra phic system creates the black boot program, including an 

of confidence that the program file has not changed may be cmpty key/option table. This black boot program is provided 

inferred. 60 l0 tne end-user in object form (without header, hash, 

If, however, the hash values do not match, the initializa- signature, hash of the key/option table, and the key/option 

tion is aborted by exiting to step 427 to erase the crypto- table itself). The end-user generates the key/option table and 

graphic keys, as described above. Cryptographic processor delivers a hash of the table to the manufacturer. The manu- 

110 is then moved into the non-functioning state. facturer concatenates the hash to the black boot image, 

A match of hash values moves the initialization procedure 65 hashes and signs the resulting image with the private key 

to its final check where is checks digital signature 550. corresponding to the public key stored in the VROM 282. 

Digital signature 550 is created by encrypting the hash value The signature (combined with the header, hash, signature, 
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hash of the key/option table, and the key option table itself) memory 124 is authenticated using the procedure described 
is returned to the end-user. The black boot program is for step 424. If it fails three times, then the keys are erased 
downloaded into the flash memory 124 of cryptographic and the cryptographic system 100 is place in non- 
system 100 from the host in encrypted form, in the format functioning mode. If it passes the authentication step 618, 
shown in FIG. 5. 5 then control of CPU 210 is transferred to the user application 

The black boot program's main function is to load other program, 

user-application programs into flash memory 124, or to start If the system is in wait_for_command mode, then the 

an application from flash memory 124 (if it is already there). black boot program 500 branches to step 624 and it stays in 

These user-application programs may be anything the user that step until a command is issued. The commands that may 

wants to run, and are encrypted using the format shown in 10 be issued are init_load (initialize the system to load a 

FIG. 5 and signed using the private RSAkey corresponding program into flash memory 124), start_flash (execute the 

to a public RSA key in the key/option table. Since the RSA program in flash memory 124), and load_flash (load the 

key is unknown to anyone other than the user, including the program into flash memory 124). If the command is start_ 

manufacturer of the cryptographic system, the user can run flash, then the black boot program 500 branches to step 618 

any program and ensure privacy. 15 and 620 to authenticate and execute the program in flash 

Referring again to FIG. 4, in step 440, CPU 210 deter- memory 124 as described above. Otherwise, an init_load 

mines if the black boot is authentic using the same technique command is issued. 

described above in step 424. If it is not authentic, then Upon receipt of the init_load command, the black boot 

operation is aborted to step 427 and the keys are zeroized program 500 checks the key/option table for the value of a 

and the cryptographic system 100 is placed in a non- 20 challenge/response bit in step 628 . If it is set, then a 

functioning state awaiting a reset. If it is authentic, then the challenge response procedure is executed in step 632. The 

black boot program is loaded into RAM, and control of CPU challenge/response procedure involves host communication 

210 is transferred to the black boot program. to determine that the host is authorized to load the applica- 

FIG. 6, illustrates in flow diagram format, an exemplary tion into flash. The black boot program 600 generates a 

black boot program 600. In step 604, black boot program random number known as ChallengelD. ChallengelD is 

600 calculates new DES keys from RTC RAM 255, VROM hashed and sent to the host, which attaches its own hashed 

282, and ROM 240, since these were zeroized during step random number and digitally signs them both using a private 

430. Using these DES keys, data may be transferred over the key, corresponding to a public key in the key/options table, 

secure bus 120. User applications, when stored in flash 3Q These are sent back to the CPU 210, which decrypts them 

memory 124 are DES encrypted according to the format with the private key. 

shown in FIG. 5, If the challenge response procedure fails, the black boot 

In step 608, black boot program validates the key/option program 500 is aborted to step 427, the keys are zeroized and 

table. In step 612, if the key/option table is valid, then the the cryptographic system is placed in a non-functioning 

execution continues with step 614. If not, then the execution 35 state. Otherwise, the black boot program 500 branches to 

is aborted to step 427, the keys are zeroized and the step 636, where it waits for a command. If the command is 

cryptographic system 100 enters a non-functioning state, a load_flash command, then the program is authenticated in 

waiting for a chip reset. step 638. If it fails, the program aborts to step 427, and if it 

In step 614, a decision is made on what mode the succeeds then the user-application program is stored in the 

cryptographic system is operating in. The black boot pro- 40 DES encrypted format of FIG. 5 in flash memory 124. If it 

gram 600 has two modes, start_up_im mediate and wait_ * a start_flash command, then the program in flash is 

for_command. If the system is in start_up_immediate executed, after authentication. 

mode, then at this point the black boot program 600 The following is pseudocode that is appropriate for use as 

branches to step 618. In step 618, the program in flash black boot program 500. 



bb_start: 

Send "abb_initializing" status to the host 
calculate the DES_KEY from seeds 
validate KOT_hash 
if KOT_hash is invalid 

/'This a fatal error"/ 

clear all RTC RAM 

Send *'abb__kot_hash_failed" status to the host 
wait for reset 
END /*KOT hash not verified*/ 
IF START_UP is set to start Flash image 

/•We drop here if START_UP option is set to immediate mode'/ 
start_flash( ) /'There will be not return*/ 
/*The START_UP option is set to command mode*/ 
IF WAIT_FOR_COM M AND suboption is set 
main_loop: 

wait_for_command( ): 

IF received START_FLASH command 

/*The host has to feed the correct sequence of 

INIT_LOAD, LOAD_FLASHs or rely on the image to be in 

Flash V 

Send "abb_starting_flash M 
start__from_ flash ( ) 
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-continued 



END 

IF received IN IT LOAD command 
IF CHALLANGE_RESPONSE is not set 
reset encode 

else encode - chalIenge_rcsponse( ) 
IF (encode) 

clear application area in RTC RAM 
goto main_loop 
END 

/•The application is authorized to load Flash*/ 
Send "abb_proceed_load" to the host 
DO FOREVER 
wait_for_command( ) 

/*The host is responsible to issue START-FLASH and 

LOAD__FLASHV 
/*in correct order"/ 
IF received STAKT_ FLASH 
start_flash( ) 
IF received LOAD_FLASH 
/•All addresses, sizes and other parameters are in the 
mailbox/* load_block( ) 
END /-DO FOREVER*/ 

END 

END 

/•The command was not recognized (it was none of 
START_FLASH, INIT_LOAD*/ goto main_loop 
END 

/•We drop here is START-UP option isn't set*/ 
stait_flash( ) /*There will be no return "/ 
procedure start_flash: 

check hash and signature 
IF any of these didn't check up to 3 times 
erase application area in RTC RAM 

send "abb e flash" status to the host 

goto main_loop 
END 

extract entry_point out of the application header 
IF APPLICATTON_NAME option did not pass validation 
Send "abb_ename" to host 
erase application area in RTC RAM 
goto main_loop 
END 

/•Here we actually start the secure application*/ 
transfer control to the entry point 

END start_flash 
procedure load_flash 

Send "abb_loading" to the host 

read and validate load parameters, translate addresses if 
needed 

unenvelope the RAM block using ENVELOPING option 
encrypt the data with the precomputed DEC key 
transfer the encrypted block to Flash 
Challenge/Response procedure 



Message - (Rand Fill || Challenge ID) 

Hash ° SHA1 (Message) 

Signature - RSAprLv(Hash) 

Response - Message || Signature 
compute ChallengelD 
send ChallengelD (challenge) to the host 
receive the response and verify all fields 
IF error 

return E_MSG 
IF response.CballengeID I -ChallengelD 
return E_ID 

calculate hash of (RandFill (| ChallengelD) from response 
verify signature of the hash 
IF verification_error 

return E_SGN 
ELSE 

return E_OK 



It can easily be envisioned that using the principles of this 
invention, application programs may be distributed in a 
variety of ways and maintain a level of security. For 
example, files may be sent over networks, such as the 
Internet, where there is great opportunity for mischief, but 



the sender and receiver can have a great deal of confidence 
that the program that ends up running on the system has not 
65 been altered or replaced. Furthermore, a seller of software 
for secure systems may ensure that all systems running its 
software are authorized users. 



04/22/2004, EAST Version: 1.4.1 



US 6,378, 

15 

Referring again to step 412, if the program to be executed 
is a normal program, then in step 450, CPU 210 examines an 
ICF flag in the VROM 282. The ICF flag is set at the 
manufacturer, and is put in place to meet certain govern- 
mental regulations about exporting cryptographic systems. 5 
If the ICF flag is set, then no program is allowed to run that 
is not digitally signed, even in normal mode. This prevents 
unauthorized programs from running, as the U.S. Govern- 
ment will not allow export of certain cryptographic tech- 
niques If the ICF flag is not set, then any program may be 10 
run, even if it is not digitally signed, in normal mode. 

If the ICF flag is set, then the program must be authen- 
ticated just as it is in the secure mode. Steps 655-665 are 
similar to steps 416 through 424 described above. However, 
the program file may be any program that has been properly 15 
authenticated. If it is authenticated, then in step 470, control 
of CPU 210 is transferred to the program. If it is not 
authenticated, then the keys are zeroized and the crypto- 
graphic system enters a non-functional state in step 427. 

If the ICF flag is not set, then the system simply loads 20 
default keys in step 475 and loads a program from the host 
in step 480. The program is checked to ensure that it is 
correct, but no digital signature is provided. If it is correct, 
then it is executed in step 470, and if not then the program 
aborts to step 427 as described above. 25 

Although specific embodiments of the present invention 
have been included herein, these are given by way of 
example only. The invention is not limited, except by the 
attached claims. One of skill in the art can readily envision 3Q 
variations and alternatives to the cited examples that do not 
depart from the spirit of the present invention. Such varia- 
tions and alternatives are anticipated by this invention. 

What is claimed is: 

1. A cryptographic system comprising: 35 

a bus interface for transferring data between the crypto- 
graphic system and an external source; 

a processor, the processor receiving data from the bus 
interface, and constructing from the data a plurality of 
exponentiation tasks; 40 

a plurality of exponentiation units, the processor trans- 
ferring each of the plurality of exponentiation tasks to 
a corresponding one of the plurality of exponentiation 
units so that the plurality of exponentiation tasks can be 
performed substantially in parallel by the plurality of 45 
exponentiation units in order to speed up system 
operations, and the plurality of exponentiation units 
returning results of the plurality of exponentiation tasks 
to the processor; and 

initialization means opera tively coupled to the processor 50 
and configured to place the cryptographic system in a 
secure state after system reset and allow execution of a 
secure program, but prior to each execution the secure 
program is verified and authenticated via the processor. 
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2. The cryptographic system of claim 1 wherein at least 
one of the plurality of exponentiation units is on a first 
integrated circuit and the processor is on a second integrated 
circuit. 

3. The cryptographic system of claim 2, further compris- 
ing: 

a first encryption engine on the first integrated circuit; 
a second encryption engine on the second integrated 
circuit; 

a secure bus, whereby when data is transferred from the 
first integrated circuit to the second integrated circuit, 
it is encrypted by the first encryption engine. 

4. The cryptographic system of claim 3 wherein the 
second encryption engine decrypts the data. 

5. A method of initializing a cryptographic system, com- 
prising: 

decrypting by the cryptographic system an encrypted 
packet with a load program to create an original load 
program; 

authenticating and validating the original load program; 
and 

if the original load program is determined to be a secure 
load file and is authenticated, placing the cryptographic 
system in a secure mode, and 

authenticating a secondary loader program, wherein the 
secondary loader program can be customized for a 
user by placing a personalized key in a table, and 
wherein the secondary loader program is configured, 
in response to a load command from the crypto- 
graphic system, to allow a user program to be 
loaded and stored in memory if the user program 
is authenticated, the user program being signed by 
a private key corresponding to the personalized 
key that is known only to the user, and 
in response to a start command from the crypto- 
graphic system, to execute the stored user program 
if it is authenticated; 
each time the cryptographic system is initialized upon 
power up, if the system is initialized in a secure mode, 
generating cryptographic keys, including the first 
decryption key, from seed values held securely in the 
cryptographic system. 

6. A method as in claim 5 further comprising: 

if the original load program is determined to be a normal 

load file and is authenticated, determining the state of 

an exporting regulation flag, so that 
if the exporting regulation flag is set authenticating a 

program before allowing it to execute, and 
if the exporting regulation flag is reset allowing the 

program to execute in normal mode. 
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DATED : April 23, 2002 

INVENTOR(S) : Thomas Collins et al. 



It is certified that error appears in the above-identified patent and that said Letters Patent is 
hereby corrected as shown below: 



Column 2, 
Line 22, insert: 

-- The Chinese Remainder Theorem allows the necessary computations to be divided 
into two exponentiations. Commonly assigned U.S. Patent 5,848,159 filed 
January 16, 1997, which is incorporated by reference for all purposes, discloses a 
method of using multiple prime numbers to create the composite number and further 
dividing the exponentiations into multiple smaller exponentiations. However, though the 
encrypting and decrypting exponentiations are smaller and therefore more quickly 
accomplished, the factorization of the composite number is no easier to compute. 
So, the security of the system is not comprised. -- 

Column 6, 
Line 38, reads: 

"the host (not shown) via messages that connects the system" 
it should read: 

-- the host (not shown) via messages that connect the system - 
Line 59, reads: 

"tioned patent application Ser. No. 08/085,993, which was" 
it should read: 

- tioned patent application Ser. No. 08/784,453, which was -- 

Column 9, 
Line 51, reads: 

"graphic system 100 is reset. Since the initialization apro-" 
it should read: 

-- graphic system 100 is reset. Since the initialization pro- - 
Line 66, reads: 

"to its final check where is checks digital signature 550." 
it should read: 

- to its final check where it checks digital signature 550. -- 

Column 10, 
Line 21 reads: 

"and the cryptographic system 100 placed in the non-" 
it should read: 

« and the cryptographic system 100 is place in the non- -- 
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It is certified that error appears in the above- identified patent and that said Letters Patent is 
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Column 10 cont'd, 
Line 22, reads: 
"functioning state 462." 
it should read: 
- functioning state 402. -- 
Line 26, reads: 

"ately upon detection of a anomaly in the checking scheme," 
it should read: 

-- ately upon detection of an anomaly in the checking scheme, --. 

Column 12, 
Line 3 reads: 

"and the cryptographic system 100 is place in non-" 
it should read: 

-- and the cryptographic system 100 is placed in non- -- 

Column 15, 
Line 2, reads: 

"is a normal program, then in step 450, CPU 210 examines an" 
it should read: 

-- is a normal program, then in step 650, CPU 210 examines an -- 
Line 16, reads: 

"authenticated. If it is authenticated, then in step 470, control" 
it should read: 

-- authenticated. If it is authenticated, then in step 670, control --; 
Line 21, reads: 

"default keys in step 475 and loads a program from the host" 
it should read: 

-- default keys in step 675 and loads a program from the host — ; 
Line 22, reads: 

"in step 480. The program is checked to ensure that it is" 
it should read: 

-- in step 680. The program is checked to ensure that it is --; 
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Column 15 cont'd. 
Line 24, reads: 

"then it is executed in step 470, and if not then the program" 
it should read; 

~ then it is executed in step 670, and if not then the program --. 
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